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Real party in interest 

Asset Reliance, Inc. (dba Asset Trust, Inc.) 
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Related appeals 

An Appeal for U.S. Patent Application 09/764,068 filed on January 19, 2001 may be affected by 
or have a bearing on this appeal. An Appeal for U.S. Patent Application 10/645,099 filed on 
August 21 , 2003 may be affected by or have a bearing on this appeal. 
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Status of Claims 

Claims 34 - 52, 62 - 64, 68 - 70, 90, 91 and 134 are rejected and are the subject of this appeal. 
Claims 62, 68, 90, 91 and134 are currently amended. Claims 1 - 33, 53 - 61 , 65 - 67, 71 - 89, 
and 92 - 133 are cancelled. Claims 135 - 167 are new. 



Serial No: 09/940,450 



5 



Status of Amendments 

An Amendment after a Non-Final Rejection was received on September 1 , 2006. 
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Summary of Claimed Subject Matter 

One embodiment of an automated method of and system for identifying measuring and 
enhancing categories of value for a value chain according to the present invention is best 
depicted in Figures 1 - 10 of the specification for the instant application. Figure 1 gives an 
overview of the major processing steps which include integrating data from a plurality of 
database management systems for use in analysis, analyzing the data as required to develop a 
model of value chain financial performance by element and category of value, identify and 
analyze value improvements and produce reports. 

Independent claim 34 - One embodiment of an automated method of and system for 
identifying measuring and enhancing categories of value for a value chain is exemplified in 
independent claim 34 where a computer readable media causes a computer to implement a 
process that integrates data from a plurality of management systems using xml and a common 
schema to support organization processing. Before the processing begins a user specifies the 
data integration settings as described in FIG. 5A reference numbers 202 and 203 and line 16, 
page 27; though line 9, page 30 of the specification. After the settings are established, data 
from each database are extracted, converted and stored in the application database for use in 
analysis. The extraction, conversion and storage of data from the basic financial system 
database in accordance with the established settings is described in FIG 5A, reference numbers 
207, 208, 209 and 211 and line 17, page 30 through line 32, page 31 of the specification. The 
extraction, conversion and storage of data from operation management system in accordance 
with the established settings is described in FIG 5B, reference numbers 221, 222, 209 and 211 
and line 3, page 32 through line 32, page 32 of the specification. The extraction, conversion 
and storage of data from a human resource management system in accordance with the 
established settings is described in FIG 5B, reference numbers 225, 226, 209 and 211 and line 
5, page 33 through line 32, page 33 of the specification. The extraction, conversion and storage 
of data from external databases in accordance with the established settings is described in FIG 
5C, reference numbers 241, 242, 209 and 211 and line 7, page 34 through line 33, page 34 of 
the specification. The extraction, conversion and storage of data from an advanced finance 
system in accordance with the established settings is described in FIG 5C, reference numbers 
245, 246, 209 and 211 and line 7, page 35 through line 33, page 35 of the specification. The 
extraction, conversion and storage of data from soft asset management systems in accordance 
with the established settings is described in FIG 5D, reference numbers 261, 262, 209 and 211 
and line 7, page 36 through line 3, page 37 of the specification. The extraction, conversion and 
storage of data from the internet in accordance with the established settings is described in FIG 
5D, reference numbers 266, 267, 268 and 269 and line 19, page 37 through line 31, page 38 of 
the specification. Text data and geospatial measures are extracted and stored in the integrated 
database as described in FIG 5D, reference numbers 268, 269 and 271, FIG. 5E, reference 
numbers 277, 278, 279, 280, 281 and 282 and line 32, page 38 through line 33, page 41 of the 
specification. The stored data are then processed to identify and locate missing data, as 
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described in FIG. 5F reference number 291 and 292 and line 1, page 42 through line 17, page 
42 of the specification. 

Dependent claims 

The limitations and activities associated with dependent claim 35 are found a number of 
places including Table 16, page 29 of the specification. 

The limitations and activities associated with dependent claim 36 are found in a number 
of places including lines 2-5, page 2, line 19-23 and Table 16 page 29 of the specification. 

The limitations and activities associated with dependent claim 37 are found in a number 
of places including line 8, page 29 of the specification. 

The limitations and activities associated with dependent claim 38 are found in a number 
of places including line 8, page 29 of the specification. 

The limitations and activities associated with dependent claim 39 are found in a number 
of places including line 1, page 29 through line 6, page 30 of the specification, the development 
and use of a common data dictionary to support data extraction, conversion and storage are 
also described in line 40, column 35 through line 15, column 38 of cross referenced U.S. Patent 
5,615,109. 

The limitations and activities associated with dependent claim 40 are found in a number 
of places including line 1 , page 29 through line 6, page 30 of the specification. 

The limitations and activities associated with dependent claim 41 are found in a number 
of places including FIG. 1 reference numbers 5, 10, 15, 30 and 35 FIG 5A, reference numbers 
207, 208, 209 and 211; FIG 5B, reference numbers 221, 222, 225, 226, 209 and 211 FIG 5C, 
reference numbers 245, 246, 209 and 211; FIG 5D, reference numbers 261, 262, 209 and 211 
and line 17, page 30 through line 3, page 37 of the specification. 

The limitations and activities associated with dependent claim 42 are found in a number 
of places including FIG. 1 reference numbers 25 and 40, FIG 5C, reference numbers 241, 242, 
209 and 211, FIG 5D, reference numbers 266, 267, 268 and 269 line 7, page 34 through line 
33, page 34 and line 19, page 37 through line 31, page 38 of the specification. 

The limitations and activities associated with dependent claim 43 are found in a number 
of places including FIG. 5A reference number 207 and 208 and line 20 - 23 on page 30 of the 
specification. 

Independent claim 44 - A second embodiment of an automated method of and system for 
identifying measuring and enhancing categories of value for a value chain is exemplified in 
independent claim 44 where a method integrates data from a plurality of management systems 
using xml and a common schema in order to support organization processing. Before the 
method begins a user specifies the data integration settings as described in FIG. 5A reference 
numbers 202 and 203 and line 16, page 27; though line 9, page 30 of the specification. After 
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the settings are established, data from each database are extracted, converted and stored in 
the application database for use in analysis. The extraction, conversion and storage of data 
from the basic financial system database in accordance with the established settings is 
described in FIG 5A, reference numbers 207, 208, 209 and 211 and line 17, page 30 through 
line 32, page 31 of the specification. The extraction, conversion and storage of data from 
operation management system in accordance with the established settings is described in FIG 
5B, reference numbers 221, 222, 209 and 211 and line 3, page 32 through line 32, page 32 of 
the specification. The extraction, conversion and storage of data from a human resource 
management system in accordance with the established settings is described in FIG 5B, 
reference numbers 225, 226, 209 and 211 and line 5, page 33 through line 32, page 33 of the 
specification. The extraction, conversion and storage of data from external databases in 
accordance with the established settings is described in FIG 5C, reference numbers 241, 242, 
209 and 211 and line 7, page 34 through line 33, page 34 of the specification. The extraction, 
conversion and storage of data from an advanced finance system in accordance with the 
established settings is described in FIG 5C, reference numbers 245, 246, 209 and 211 and line 
7, page 35 through line 33, page 35 of the specification. The extraction, conversion and storage 
of data from soft asset management systems in accordance with the established settings is 
described in FIG 5D, reference numbers 261, 262, 209 and 211 and line 7, page 36 through line 
3, page 37 of the specification. The extraction, conversion and storage of data from the internet 
in accordance with the established settings is described in FIG 5D, reference numbers 266, 
267, 268 and 269 and line 19, page 37 through line 31, page 38 of the specification. Text data 
and geospatial measures are extracted and stored in the integrated database as described in 
FIG 5D, reference numbers 268, 269 and 271, FIG. 5E, reference numbers 277, 278, 279, 280, 
281 and 282 and line 32, page 38 through line 33, page 41 of the specification. The stored data 
are then processed to identify and locate missing data, as described in FIG. 5F reference 
number 291 and 292 and line 1, page 42 through line 17, page 42 of the specification. 

Dependent claims 

The limitations and activities associated with dependent claim 45 are found a number of 
places including line 8 and Table 16 on page 29 of the specification. 

The limitations and activities associated with dependent claim 46 are found in a number 
of places including lines 2-5, page 2, line 19-23 and Table 16 on page 29 of the 
specification. 

The limitations and activities associated with dependent claim 47 are found in a number 
of places including line 1, page 29 through line 6, page 30 of the specification, the development 
and use of a common data dictionary to support data extraction, conversion and storage are 
also described in line 40, column 35 through line 15, column 38 of cross referenced U.S. Patent 
5,615,109. 

The limitations and activities associated with dependent claim 48 are found in a number 
of places including line 1 , page 29 through line 6, page 30 of the specification. 
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The limitations and activities associated with dependent claim 49 are found in a number 
of places including FIG. 1 reference numbers 5, 10, 15, 30 and 35 FIG 5A, reference numbers 
207, 208, 209 and 211; FIG 5B, reference numbers 221, 222, 225, 226, 209 and 211 FIG 5C, 
reference numbers 245, 246, 209 and 211; FIG 5D, reference numbers 261, 262, 209 and 211 
and line 17, page 30 through line 3, page 37 of the specification. 

The limitations and activities associated with dependent claim 50 are found in a number 
of places including FIG. 1 reference numbers 25 and 40, FIG 5C, reference numbers 241, 242, 
209 and 211, FIG 5D, reference numbers 266, 267, 268 and 269 line 7, page 34 through line 
33, page 34 and line 19, page 37 through line 31, page 38 of the specification. 

The limitations and activities associated with dependent claim 51 are found in a number 
of places including FIG. 5A reference number 207 and 208 and line 20 - 23 on page 30 of the 
specification. 

The limitations and activities associated with dependent claim 52 were already described 
for claim 34 - this claim should have been cancelled. 

Independent claim 62 - A third embodiment of an automated method of and system for 
identifying measuring and enhancing categories of value for a value chain is exemplified in 
independent claim 62 where a computer readable media causes a computer to integrate data 
from a plurality of management systems for use in analysis in accordance with a common 
schema and analyze the data in order to create a plurality of tools for organization management. 
More specifically, data from the database management systems associated with a plurality of 
enterprise transaction systems are prepared for use in processing by integrating, converting and 
storing the data in accordance with a common schema as described in FIG. 1, reference 
number 200, FIG. 5A reference numbers 201 - 204, 207 - 209 and 211 FIG. 5B reference 
numbers 221 - 222, 225 - 226, 209 and 211 , FIG. 5C reference numbers 241 - 242, 245 - 246, 
209 and 211, FIG. 5D reference numbers 261 - 262, 265, 267, 269, 209 and 211, FIG. 5E 
reference numbers 277 - 282, FIG. 5F reference numbers 292 - 297, and line 1, page 14 through 
line 35, page 43 of the specification. The integrated data are then analyzed using a plurality of 
bots in order to develop a market value model for a value chain that uses analytical models, 
including network models, to identify a tangible impact of each element of value on each 
category of value and each component of value in accordance with the procedure detailed in 
FIG. 1, reference numbers 300 and 400, FIG. 6A reference number 302 - 310, FIG. 6B 
reference numbers 321, 323 and 326 - 329, FIG. 6C reference numbers 341 - 343 and 345 - 
350 FIG. 7 reference numbers 404, 404 and 409 - 415 and line 1, page 44 through line 18, 
page 65 of the specification. The value chain model is then used to develop management 
reports as described in FIG. 8 reference numbers 504 - 507 and line 20, page 65 through line 
18, page 69 of the specification. The previously calculated information is then used to support 
the automated trading of organization equity as described in FIG. 8 reference numbers 509 - 
512 and line 20 page 69 and line 18, page 70 of the specification. The value chain model is 
then used for simulation and optimization using the method described in FIG. 9 reference 
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number 603 - 605 and 610 and lines 20, page 71 through line 17, page 73 of the specification. 
The results of the analyses include lists of changes that will optimize one or more aspects of 
organization financial performance. The results are reported using the method described in 
FIG. 9 reference number 611 and 612 and lines 20, page 73 through line 30, page 73 of the 
specification. 

Dependent claims 

The limitations and activities associated with dependent claim 63 are found in a number 
of places including line 9 through 13, page 73 of the specification. 

The limitations and activities associated with dependent claim 64 are found in a number 
of places including FIG. 1 reference numbers 5, 10, 15, 30 and 35 FIG 5A, reference numbers 
207, 208, 209 and 211; FIG 5B, reference numbers 221, 222, 225, 226, 209 and 211 FIG 5C, 
reference numbers 245, 246, 209 and 211; FIG 5D, reference numbers 261, 262, 209 and 211 
and line 17, page 30 through line 3, page 37 of the specification. 

The limitations and activities associated with dependent claim 68 are found in a number 
of places including line 1, page 29 through line 6, page 30 of the specification, the development 
and use of a common data dictionary to support data extraction, conversion and storage are 
also described in line 40, column 35 through line 15, column 38 of cross referenced U.S. Patent 
5,615,109. 

The limitations and activities associated with dependent claim 69 are found in a number 
of places including line 1 , page 29 through line 6, page 30 of the specification. 

The limitations and activities associated with dependent claim 70 are found in a number 
of places including line 8, page 29 of the specification. 

The limitations and activities associated with dependent claim 90 are found in a number 
of places including table 3, page 10. 

The limitations and activities associated with dependent claim 91 are found in a number 
of places including table 3, page 10. 

The limitations and activities associated with dependent claim 134 are found in a number 
of places including FIG. 6A, 6B and 6C and pages 50 - 78 of the specification. 
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Grounds of rejection to be reviewed on appeal 



Issue 1 - Whether claim 34, claim 35, claim 36, claim 37, claim 38, claim 39, claim 40, claim 41 , 
claim 42, claim 43, claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, claim 50, claim 51 
and/or claim 52 are patentable under 35 USC 103 over U.S. Patent 6,332,163 (hereinafter, 
Bowman-Amuah) in view of U.S. Patent 6,301 ,584 (hereinafter, Ranger)? 

Issue 2 - Whether claim 62, claim 63, claim 64, claim 68, claim 69, claim 70, claim 90, claim 91 
and/or claim 134 are patentable under 35 USC 103 over Bowman-Amuah in view of Ranger? 
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The Argument 

For each ground of rejection which Appellant contests herein which applies to more than one 
claim, such additional claims, to the extent separately identified and argued below, do not stand 
and fall together. 

Issue 1 - Whether claim 34, claim 35, claim 36, claim 37, claim 38, claim 39, claim 40, 
claim 41, claim 42, claim 43, claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, 
claim 50, claim 51 and/or claim 52 are patentable under 35 USC 103 over U.S. Patent 
6,332,163 (hereinafter, Bowman-Amuah) in view of U.S. Patent 6,301,584 (hereinafter, 
Ranger)? 

The claims are patentable because the claims describe an invention that produces results that 
are concrete, tangible and useful. Other reasons the claims are patentable include the fact that 
cited combination of documents used to support the rejection of claim 34, claim 35, claim 36, 
claim 37, claim 38, claim 39, claim 40, claim 41, claim 42, claim 43, claim 44, claim 45, claim 46, 
claim 47, claim 48, claim 49, claim 50, claim 51 and/or claim 52 fails to establish a prima facie 
case of obviousness. Specific reasons the cited combination fails to establish a prima facie 
case of obviousness include: 

1. the cited combination of document teachings requires a change in the principles 
governing the operation of the Bowman-Amuah and Ranger inventions; 

2. the cited combination of documents fails to teach one or more limitation for every claim; 

3. the cited combination of document teachings would destroy the ability of the Bowman- 
Amuah invention to complete its primary function of providing near-real-time predictions 
regarding web site visitors; 

4. the cited combination of documents fails to make the invention as a whole obvious by 
teaching away from the claimed methods; and 

5. the cited combination of documents teach away from their own combination. 

The Appellant notes that there is still other ways in which the cited combination fails to produce 
a prima facie case of obviousness. 

Reason #1 - The first reason that claim 34, claim 35, claim 36, claim 37, claim 38, claim 39, 
claim 40, claim 41, claim 42, claim 43, claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, 
claim 50, claim 51 and/or claim 52 are patentable is that the proposed combination of 
documents would change one or more of the principles of operation of the Bowman-Amuah and 
Ranger methods. M PEP 2143.01 provides that when "the proposed modification or combination 
of the prior art would change the principle of operation of the prior art invention being modified, 
then the teachings of the references are not sufficient to render the claims prima facie obvious. 
In re Ratti, 270 F.2d 810, 123 USPQ 349 (CCPA 1959)". As noted previously, the obviousness 
rejections are based on a combination of Bowman-Amuah and Ranger. Some of the changes in 
the operating principles of the cited documents that would be required to make the combination 
function are discussed below. 
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1 . Change from combined data access and analysis to stand alone data access . One of the 
specific goals of the Bowman-Amuah invention is to couple the access to data with the 
completion of business functions (see page 42, Evidence Appendix, Bowman-Amuah C284, 
L 9 - 1 1). The Examiner has proposed using Bowman-Amuah in combination with Ranger to 
among other things render obvious an invention for the stand alone integration of data in 
accordance with a common schema. Modifying Bowman-Amuah to separate data access 
from the completion of business functions would require a change in principle in the 
operation of the Bowman-Amuah invention. As a result, the teachings of the cited 
combination of documents are not sufficient to render the claims prima facie obvious. 

2. Change from integration based on rules to integration based on a common schema . 
Ranger teaches the integration of data using data reliability and rules on a one at a time 
basis as required to support a query (see pages 33 and 35, Evidence Appendix, Ranger C2, 
L20 - 40, C19, L32 - C20, L43). The Examiner has proposed using Ranger in combination 
with Bowman Amuah to among other things render obvious an invention for integrating data 
in accordance with a common schema. Modifying Ranger to integrate data in accordance 
with a common schema instead of rules and reliability would require a change in principle in 
the operation of the Ranger invention. As a result, the teachings of the cited combination of 
documents are not sufficient to render the claims prima facie obvious. 

3. Change from reliance on reliance on replication and synchronization services to a reliance 
on stand-alone data integration . Bowman-Amuah teaches a system that incorporates 
replication and synchronization services (see page 41 , Evidence Appendix, Bowman-Amuah 
C49, L45 - C50, L55). A replicated database often consolidates data from heterogeneous 
data sources, thus shielding the user from the processes required to locate, access and 
query the data (see page 41, Evidence Appendix, Bowman-Amuah C50, L45 - 50). The 
Examiner has proposed using Bowman-Amuah in combination with Ranger to among other 
things render obvious an invention for the stand alone integration of data in accordance with 
a common schema. There would be no need for the replication and synchronization services 
of Bowman-Amuah if stand-alone data integration . Modifying Bowman-Amuah to eliminate 
replication and synchronization services would require a change in principle in the operation 
of the Bowman-Amuah invention. As a result, the teachings of the cited combination of 
documents are not sufficient to render the claims prima facie obvious. 

Reason #2 - The second reason that the cited combination of documents fails to establish a 
prima facie case of obviousness that would support the rejection of claim 34, claim 35, claim 36, 
claim 37, claim 38, claim 39, claim 40, claim 41, claim 42, claim 43, claim 44, claim 45, claim 46, 
claim 47, claim 48, claim 49, claim 50, claim 51 and/or claim 52 is that the cited combination of 
documents does not teach or suggest one or more of the limitations for every rejected claim. 
MPEP 2142 provides that: in order to establish a prima facie case of obviousness... the prior art 
reference (or references when combined) must teach or suggest all the claim limitations. 
Limitations not taught or suggested include: 
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1) Claims 34 and 44 (affects 35 - 43 and 45 - 52). Limitations not taught or suggested 
include: 

integrating data from a variety of systems using xml and a common schema to support 

organization processing 
Neither Ranger or Bowman-Amuah teach integrating data from a variety of systems using 
xml and a common schema to support organization processing; 

2) Claims 35 and 45. Limitations and activities not taught include: 
where the common schema includes an organization designation 

Neither Ranger or Bowman-Amuah teach where the common schema includes an 
organization designation; 

3) Claims 36 and 46. Limitations and activities not taught include: 

wherein the designated organization is a single product, a group of products, a 
division, a company, a multi-company corporation or a value chain 
Neither Ranger or Bowman-Amuah teach where the designated organization is a single 
product, a group of products, a division, a company, a multi-company corporation or a 
value chain; 

4) Claims 39 and 47. Limitations and activities not taught include: 
where the common schema includes a data dictionary 

Neither Ranger or Bowman-Amuah teach where a common schema includes a data 
dictionary; 

5) Claims 40 and 48. Limitations and activities not taught include: 

where the data dictionary defines standard data attributes from the group consisting of 
account numbers, components of value, currencies, elements of value, units of 
measure and time periods 
Neither Ranger or Bowman-Amuah teach where the data dictionary defines standard data 
attributes from the group consisting of account numbers, components of value, currencies, 
elements of value, units of measure and time periods; 

6) Claims 41 and 49. Limitations and activities not taught include: 

where data are obtained from the group consisting of advanced financial systems, 
basic financial systems, alliance management systems, brand management systems, 
customer relationship management systems, channel management systems, 
intellectual property management systems, process management systems, vendor 
management systems, operation management systems, sales management systems, 
human resource systems, accounts receivable systems, accounts payable systems, 
capital asset systems, inventory systems, invoicing systems, payroll systems, 
purchasing systems and combinations thereof. 
Neither Ranger or Bowman-Amuah teach where data are obtained from the group 
consisting of advanced financial systems, basic financial systems, alliance management 
systems, brand management systems, customer relationship management systems, 
channel management systems, intellectual property management systems, process 
management systems, vendor management systems, operation management systems, 
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sales management systems, human resource systems, accounts receivable systems, 
accounts payable systems, capital asset systems, inventory systems, invoicing systems, 
payroll systems, purchasing systems and combinations thereof; 

7) Claims 43 and 51. Limitations and activities not taught include: 

where the data preparation method further comprises converting data to match a 
common schema and storing the converted data in a central database. 

Neither Ranger or Bowman-Amuah teach converting data to match a common schema 

and storing the converted data in a central database. 

Reason #3 - The third reason the cited combination of documents fails to establish a prima facie 
case of obviousness that would support the rejection of claim 34, claim 35, claim 36, claim 37, 
claim 38, claim 39, claim 40, claim 41, claim 42, claim 43, claim 44, claim 45, claim 46, claim 47, 
claim 48, claim 49, claim 50, claim 51 and/or claim 52 is that the proposed combination of 
Bowman-Amuah and Ranger would destroy the ability of the invention described by Bowman- 
Amuah to complete its primary function - serve as a fixed format stream-based communication 
system that provides for the real time transmission of data (see page 36 - 38, Evidence 
Appendix, Bowman-Amuah abstract, FIG. 20 and C3, L 6 -7). It is well established that when a 
modification of a reference destroys the intent, purpose or function of an invention such a 
proposed modification is not proper and the prima facie case of obviousness cannot be properly 
made (In re Gordon 733 F.2d 900, 221 U.S.PQ 1125 Fed Circuit 1984). As described 
previously under reason #1 , the combination of document teachings proposed by the Examiner 
would change two of the principles of operation of the Bowman-Amuah invention by changing 
from a reliance on combined data access and analysis that utilizes replication and 
synchronization services to reliance on a separate stand alone data access. However, the 
increased processing time required to complete a separate data access function that includes 
searching for data normally provided by the replication services would destroy the ability of 
Bowman-Amuah invention to complete its primary function at the required speeds. 

Because the proposed modification of the Bowman-Amuah invention would destroy the intent, 
purpose and function of the Bowman-Amuah invention, the proposed modification is improper 
and the prima facie case of obviousness cannot be made. 

Reason #4 - The fourth reason claims claim 34, claim 35, claim 36, claim 37, claim 38, claim 39, 
claim 40, claim 41, claim 42, claim 43, claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, 
claim 50, claim 51 and/or claim 52 are patentable is that the cited combination of documents 
fails to make the invention as a whole obvious as required by MPEP § 2141.02 which states 
that: "in determining the difference between the prior art and the claims, the question under 35 
U.S.C. 103 is not whether the differences themselves would have been obvious but whether the 
claimed invention as a whole would have been obvious." Furthermore, it is well established 
that: A prior art reference must be considered in its entirety, i.e., as a whole, including portions 
that would lead away from the claimed invention. W.L. Gore & Associates, Inc. v. Garlock, Inc., 
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721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 1983), cert, denied, 469 U.S. 851 (1984). The ways in 
which the cited documents (Bowman-Amuah and Ranger) lead away from the claimed invention 
include: 

1) Claims 34 and 44 (affects 35 - 43 and 45 - 52), the cited documents teach away from: 
integrating data from a variety of systems using xml and a common schema to support 
organization processing 

Bowman-Amuah teaches away from the use of xml data integration to support 
organization processing as it teaches: that xml is only for tagging and displaying data on 
web pages and that xml is going to be displaced by SMIL (see page 41- 42, Evidence 
Appendix, C 41, L 1 - 5 and C42, L5). Bowman-Amuah also teaches away by teaching 
that integration is just one of many application styles (see FIG. 4). Ranger teaches away 
by teaching that xml is useful only for formatting data for presentation (C10, L1 1 - 21) and 
by teaching integration based on rules and reliability instead of integration based on a 
common schema (see page 35, Evidence Appendix, Ranger C19, L32 - C20, L43); 

2) Claims 35 and 45, the cited documents teach away from: 
where the common schema includes an organization designation 

Both Ranger and Bowman-Amuah teach away by teaching that xml is useful only for 
presenting data on the web; 

3) Claims 36 and 46, the cited documents teach away from: 

wherein the designated organization is a single product, a group of products, a 
division, a company, a multi-company corporation or a value chain 

Both Ranger and Bowman-Amuah teach away by teaching that xml is useful only for 

presenting data on the web; 

4) Claims 39 and 47, the cited documents teach away from: 
where the common schema includes a data dictionary 

Bowman-Amuah teaches away by teaching a data dictionary that is not part of a schema; 

5) Claims 43 and 51. Limitations and activities not taught include: 

where the data preparation method further comprises converting data to match a 
common schema and storing the converted data in a central database. 

Bowman-Amuah teaches away by providing replication services that require multiple 

copies of databases (C49, L56); 

Taken together the cited combination of documents fails to make the invention as a whole 
obvious. The cited combination also fails to make a single aspect of the claimed invention 
obvious. These failures provide additional evidence that the claimed invention for producing, 
concrete, tangible and useful results is new, novel and non-obvious. 

Reason #5 - The fifth reason that claims claim 34, claim 35, claim 36, claim 37, claim 38, claim 
39, claim 40, claim 41, claim 42, claim 43, claim 44, claim 45, claim 46, claim 47, claim 48, claim 
49, claim 50, claim 51 and/or claim 52 are patentable is that the cited combination of documents 
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fails to establish a prima facie case of obviousness because they teach away from their own 
combination. MPEP § 2145 X.D.2 provides that: "it is improper to combine references where 
the references teach away from their combination." The documents teach away from the 
proposed theoretical combination in a number of ways, including: 

Teaching Incompatible data management . Ranger teaches a method for retrieving data in a 
response to a guery that gathers information dynamically from one or more data sources which 
may be located at different servers and have incompatible formats (see page 32, Evidence 
Appendix, Ranger, abstract). Bowman-Amuah teaches a system that incorporates replication 
and synchronization services (see page 41, Evidence Appendix, Bowman-Amuah C49, L45 - 
C50, L55). A replicated database often consolidates data from heterogeneous data sources, 
thus shielding the user from the processes required to locate, access and query the data (see 
page 41, Evidence Appendix, Bowman-Amuah C50, L45 - 50). It clearly would be improper to 
combine an invention that teaches and relies on obtaining data using a time consuming 
procedure in response to a query with an invention that teaches and relies on replication and 
synchronization to eliminate the need for a time consuming procedure for obtaining data in 
response to a query. 

Reason #6 The sixth reason claim 34, claim 35, claim 36, claim 37, claim 38, claim 39, claim 40, 
claim 41, claim 42, claim 43, claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, claim 50, 
claim 51 and/or claim 52 are patentable is that the prior art review for the instant application is 
apparently being completed under a different standard than that used for the review of similar 
patent applications - an apparent violation of 35 USC 3. As shown in the table below, the data 
integration invention in 09/940,450 has broad similarities to an invention disclosed by 
Warshavsky (see page 43, Evidence Appendix, Warshavsky abstract). 



09/421 ,553 - 09/940,450 specification 


Warshavsky Claim #1 


The software in block 203 prompts the user (20) via the 
metadata and conversion rules window (702) to map 
metadata using the standard specified by the user (20) 
(XML is one of the listed standards) 


Creating an XML Mapping 
Definition from metadata using a 


metadata wizard 


Map ...from the basic financial system database (5), the 
operation management system database (10), the 
human resource information system database (15), the 
external database (25), the advanced financial system 
database (30) and the soft asset management system 
database (35) to the organizational hierarchy and to the 
pre-specified fields in the metadata mapping table (141) 


Selecting relational data from a 
relational application database; 
and 


The software in block 203 prompts the user (20) via the 
metadata and conversion rules window (702) to provide 
conversion rules for each metadata field for each data 
source. Data bots then extract, convert and store data in 
accordance with mapping/conversion settings. 


Converting the relational data to 
the XML document using the XML 
Mapping Definition 



Note: In addition to having several similarities, there are several differences between the systems. For one thing 
the Asset Reliance application stores data in tables in a central database while the Siebel invention creates 
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documents. The Warshavsky metadata wizard apparently creates duplicate tags so the invention also adds a 
numerical suffix to duplicate metadata tags. The 09/421,553 and/or 09/940,450 system does not create duplicate 
metadata tags a so it does not require their removal (storing data in tables also minimizes any concern about 
duplicate tags). Another difference is that the 09/421,553 and/or 09/940,450 system extracts all the data from 
each database not just the data that matches a particular DTD. 

Issue 2 - Whether claim 62, claim 63, claim 64, claim 68, claim 69, claim 70, claim 90, 
claim 91 and/or claim 134 are patentable under 35 USC 103 over Bowman-Amuah in view 
of Ranger? 

The claims are patentable in view of the shortcomings in the arguments used to support the 
rejection of the claims and the usefulness of the results produced by the claimed invention. In 
particular, claim 62, claim 63, claim 64, claim 68, claim 69, claim 70, claim 90, claim 91 and/or 
claim 134 are allowable for the first, third, fifth and sixth reasons advanced under Issue 1. 

Reason #5 - The fifth reason claim 62, claim 63, claim 64, claim 68, claim 69, claim 70, claim 
90, claim 91 and/or claim 134 are patentable is that the cited combination fails to meet one of 
the key criteria required for establishing a prima facie case of obviousness. MPEP 2142 
provides that: in order to establish a prima facie case of obviousness... the prior art reference (or 
references when combined) must teach or suggest all the claim limitations. Limitations not 
taught or suggested include: 

1) Claim 62 (affects 63, 64, 68, 69, 70, 90, 91 and 134). Limitations not taught or 
suggested include: 

using at least a portion of said data to create one or more tools for organization 
management, and 

making the one or more tools available for review 

where the one or more tools for organization management further comprise a system for 
automated trading of organization equity and tools selected from the group consisting of 
analytical models, category of value models, component of value models, market value 
models, network models, optimization models, simulation models, value chain models, 
management reports, lists of changes that will optimize one or more aspects of 
organization financial performance and combinations thereof. 

Neither Ranger or Bowman-Amuah teach a system for automated trading of organization 
equity, category of value models, component of value models, market value models, 
network models, optimization models, simulation models, value chain models, 
management reports, lists of changes that will optimize one or more aspects of 
organization financial performance and combinations thereof; 

2) Claim 64 for the same reasons described previously for claims 41 and 49; 

3) Claim 68 for the same reasons described previously for claims 35, 39, 45 and 47; 

4) Claim 69. Limitations and activities not taught include: 

where the data dictionary defines standard data attributes from the group consisting of 
account numbers, components of value, currencies, elements of value, organization 
designations, time periods and units of measure 
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Neither Ranger or Bowman-Amuah teach where the data dictionary defines standard data 
attributes from the group consisting of account numbers, components of value, currencies, 
elements of value, organization designations, time periods and units of measure; 

5) Claim 90. Limitations and activities not taught include: 

wherein the one or more aspects of organization financial performance are selected 
from the group consisting of organization revenue, organization expense, organization 
capital change, organization current operation value, organization real option value, 
organization market sentiment value, organization market value and combinations 
thereof 

Neither Ranger or Bowman-Amuah teach where one or more aspects of organization 
financial performance are selected from the group consisting of organization revenue, 
organization expense, organization capital change, organization current operation value, 
organization real option value, organization market sentiment value, organization market 
value and combinations thereof; 

6) Claim 91. Limitations and activities not taught include: 

wherein the identified changes are changes to alliance value drivers, brand value 
drivers, channel value drivers, customer value drivers, customer relationship value 
drivers, employee value drivers, equipment value drivers, intellectual property value 
drivers, partnership value drivers, process value drivers, production equipment 
value drivers, vendor value drivers, vendor relationship value drivers, organization 
equity 

Neither Ranger or Bowman-Amuah teach where the identified changes are changes to 
alliance value drivers, brand value drivers, channel value drivers, customer value drivers, 
customer relationship value drivers, employee value drivers, equipment value drivers, 
intellectual property value drivers, partnership value drivers, process value drivers, 
production equipment value drivers, vendor value drivers, vendor relationship value 
drivers, organization equity; 

7) Claim 134. Limitations and activities not taught include: 

learns the relative importance of the different elements of value, categories of value and 
enterprises in determining organization financial performance as required to support the 
development of one or more tools for organization management 
Neither Ranger or Bowman-Amuah teach anything about learning from the data. 



Please note: The prosecution of other applications in the Asset Trust portfolio has identified 
additional documents. However, given the newly announced emphasis on disclosing only "non- 
cumulative" documents, the Appellant has elected not to disclose a number of U.S. Patents 
including 5,148,365; 5,508,731; 5,779,287; 5,873,070; 5,930,774; 6,026,388; 6,205,150; 
6,401,070; 6,456,982; 6,457,049; 6,591,232; 6,684,193; 6,742,054 and 7,162,427 as well as the 
non-patent-literature produced for applications 10/166,758; 10/237,021 and 10/743,616. 
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consists of an improper combination of documnrca For thstt reason and the extensive reasons 
hated below the Appoint rsspsafuily bj.it forcsfoily contends that each ciacc * patentee 

Tnc Appellant notes- tost with respect to the prosecutor, of the instant application, it appears 
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CLAIMS APPENDIX 



34. A computer readable medium having sequences of instructions stored therein, which when 
executed causes a processor in a computer to perform a data preparation method, comprising 
integrating data from a variety of systems using xml and a common schema to support 
organization processing. 

35. The computer readable medium of claim 34 where the common schema includes an 
organization designation. 

36. The computer readable medium of claim 35 wherein the designated organization is a single 
product, a group of products, a division, a company, a multi-company corporation or a value 
chain. 

37. The computer readable medium of claim 34 where the common schema includes a data 
structure. 

38. The computer readable medium of claim 37 where the data structure is a hierarchy. 

39. The computer readable medium of claim 34 where the common schema includes a data 
dictionary. 

40. The computer readable medium of claim 39 where the data dictionary defines standard 
data attributes from the group consisting of account numbers, components of value, currencies, 
elements of value, units of measure and time periods. 

41. The computer readable medium of claim 34 where data are obtained from the group 
consisting of advanced financial systems, basic financial systems, alliance management 
systems, brand management systems, customer relationship management systems, channel 
management systems, intellectual property management systems, process management 
systems, vendor management systems, operation management systems, sales management 
systems, human resource systems, accounts receivable systems, accounts payable systems, 
capital asset systems, inventory systems, invoicing systems, payroll systems, purchasing 
systems and combinations thereof. 

42. The computer readable medium of claim 34 wherein at least a portion of the data are from 
the Internet or an external database. 
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43. The computer readable medium of claim 34 where the data preparation method further 
comprises converting data to match a common schema and storing the converted data in a 
central database. 

44. A data preparation method, comprising: 

integrating data from a variety of systems using xml and a common schema to support 
organization processing. 

45. The method of claim 44 where the common schema includes an organization designation 
and data structure. 

46. The method of claim 45 wherein the designated organization is a single product, a group of 
products, a division, a company, a multi-company corporation or a value chain. 

47. The method of claim 44 where the common schema includes a data dictionary 

48. The method of claim 47 where the data dictionary defines standard data attributes from the 
group consisting of account numbers, components of value, currencies, elements of value, units 
of measure and time periods. 

49. The method of claim 44 where data are obtained from the group consisting of advanced 
financial systems, basic financial systems, alliance management systems, brand management 
systems, customer relationship management systems, channel management systems, 
intellectual property management systems, process management systems, vendor 
management systems, operation management systems, sales management systems, human 
resource systems, accounts receivable systems, accounts payable systems, capital asset 
systems, inventory systems, invoicing systems, payroll systems and purchasing systems. 

50. The method of claim 44 wherein at least a portion of the data are from the Internet or 
external databases. 

51. The method of claim 44 where the data preparation method further comprises converting 
and storing data in accordance with a common schema. 

52. A computer readable medium having sequences of instructions stored therein, which when 
executed cause the processors in a plurality of computers connected via a network to perform 
the data preparation method of claim 44. 
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62. A computer readable medium having sequences of instructions stored therein, which when 
executed cause a set of processors in a plurality of computers that have been connected via a 
network to perform an organization management method, comprising: 

integrating a plurality of organization related data from a variety of sources in accordance 
with a common schema, 

using at least a portion of said data to create one or more tools for organization 
management, and 

making the one or more tools available for review 
where the one or more tools for organization management further comprise a system for 
automated trading of organization equity and tools selected from the group consisting of 
analytical models, category of value models, component of value models, market value 
models, network models, optimization models, simulation models, value chain models, 
management reports, lists of changes that will optimize one or more aspects of organization 
financial performance and combinations thereof. 

63. The computer readable medium of claim 62 where the one or more tools are made 
available for review using an electronic display, a paper document or combinations thereof. 

64. The computer readable medium of claim 62 where data are obtained from advanced 
financial systems, basic financial systems, alliance management systems, brand management 
systems, customer relationship management systems, channel management systems, 
estimating systems, intellectual property management systems, process management systems, 
supply chain management systems, vendor management systems, operation management 
systems, enterprise resource planning systems (ERP), material requirement planning systems 
(MRP), quality control systems, sales management systems, human resource systems, 
accounts receivable systems, accounts payable systems, capital asset systems, inventory 
systems, invoicing systems, payroll systems, purchasing systems, web site systems, the 
Internet, external databases, user input and combinations thereof. 

68. The computer readable medium of claim 62, where the common schema defines common 
attributes selected from the group consisting of data structure, organization designation, data 
dictionary and combinations thereof. 

69. The computer readable medium of claim 68 where the data dictionary defines standard 
data attributes from the group consisting of account numbers, components of value, currencies, 
elements of value, organization designations, time periods and units of measure. 
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70. The computer readable medium of claim 68 where the data structure is a hierarchy. 

90. The computer readable medium of claim 62, wherein the one or more aspects of 
organization financial performance are selected from the group consisting of organization 
revenue, organization expense, organization capital change, organization current operation 
value, organization real option value, organization market sentiment value, organization market 
value and combinations thereof. 

91. The computer readable medium of claim 62, wherein the identified changes are changes to 
alliance value drivers, brand value drivers, channel value drivers, customer value drivers, 
customer relationship value drivers, employee value drivers, equipment value drivers, 
intellectual property value drivers, partnership value drivers, process value drivers, production 
equipment value drivers, vendor value drivers, vendor relationship value drivers, organization 
equity and combinations thereof. 

134. The computer readable medium of claim 62 that learns the relative importance of the 
different elements of value, categories of value and enterprises in determining organization 
financial performance as required to support the development of one or more tools for 
organization management. 

135. A data preparation system, comprising: 

a computer with a processor having circuitry to execute instructions; a storage device available 
to said processor with sequences of instructions stored therein, which when executed cause 
the processor to: 

integrate a plurality of data from a plurality of organization related systems and an Internet 

using xml and a common schema, and 

store said data in an application database for use in processing 
where an application database further comprises a central database that makes the data 
accessible and available for extraction and analysis so as to provide a coherent view of the 
data for an enterprise. 

136. The system of claim 135, wherein storing said data in an application database for use in 
processing further comprises using metadata mapping to convert and store data in accordance 
with a common schema. 

137. The system of claim 135, wherein a common schema includes attributes selected from 
the group consisting of organization designation, data structure, metadata standard, data 
dictionary and combinations thereof. 
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138. The system of claim 137, wherein an organization designation further comprises a single 
product, a group of products, a division, a company, a multi-company corporation or a value 
chain. 

139. The system of claim 137, wherein a common schema further comprises a data dictionary 
where the data dictionary defines standard data attributes selected from the group consisting of 
account numbers, components of value, currencies, elements of value, units of measure, time 
periods and combinations thereof. 

140. The system of claim 135, wherein a plurality of organization related systems are database 
management systems for systems selected from the group consisting of advanced financial 
systems, basic financial systems, alliance management systems, brand management systems, 
customer relationship management systems, channel management systems, intellectual 
property management systems, process management systems, vendor management systems, 
operation management systems, sales management systems, human resource systems, 
accounts receivable systems, accounts payable systems, capital asset systems, inventory 
systems, invoicing systems, payroll systems, purchasing systems and combinations thereof. 

141. A program storage device readable by machine, tangibly embodying a program of 
instructions executable by a machine to perform the method steps in a data processing method, 
comprising: 

use metadata mapping to integrate a plurality of data from a plurality of systems in 
accordance with xml and a common schema to support organization processing 
where metadata mapping is guided by a metadata mapping table. 

142. The program storage device of claim 141 , wherein at least some data are pre-specified 
for integration. 

143. The program storage device of claim 141 , wherein a plurality of integrated enterprise data 
are converted and stored in an application database in accordance with a common schema. 

144. The program storage device of claim 141, wherein a set of integration and conversion 
rules are established using a metadata and conversion rules window and saved in a metadata 
mapping table. 

145. A data method, comprising using metadata mapping to integrate a plurality of data from a 
plurality of enterprise related systems in accordance with xml and a common schema to support 
organization processing where metadata mapping is guided by a metadata mapping table. 



Serial No: 09/940,450 



26 



146. The method of claim 145, wherein a plurality of systems are selected from the group 
consisting of advanced financial systems, basic financial systems, alliance management 
systems, brand management systems, customer relationship management systems, channel 
management systems, intellectual property management systems, process management 
systems, vendor management systems, operation management systems, sales management 
systems, human resource systems, accounts receivable systems, accounts payable systems, 
capital asset systems, inventory systems, invoicing systems, payroll systems, enterprise 
resource planning systems (ERP), material requirement planning systems (MRP), scheduling 
systems, supply chain systems, quality control systems, purchasing systems, risk management 
systems, the Internet and combinations thereof. 

147. The method of claim 145, wherein a metadata and conversion rules window is used to 
establish a metadata mapping table and a conversion rules table. 

148. The method of claim 145, wherein a common schema identifies data designations 
selected from the group consisting of components of value, sub components of value, known 
value drivers, elements of value, sub elements of value, non-relevant attributes and 
combinations thereof. 

149. The method of claim 145, wherein a data method further comprises storing a plurality of 
converted data in one or more tables to support organization processing. 

150. A data preparation system, comprising: 

a computer with a processor having circuitry to execute instructions; a storage device available 
to said processor with sequences of instructions stored therein, which when executed cause 
the processor to: 

use metadata mapping to integrate and convert a plurality of data from a plurality of 
enterprise related systems in accordance with xml and a common schema to support 
organization processing 

where metadata mapping is guided by a metadata mapping table, and 
where a plurality of enterprise related systems are selected from the group consisting of 
advanced financial systems, basic financial systems, alliance management systems, 
brand management systems, customer relationship management systems, channel 
management systems, intellectual property management systems, process management 
systems, vendor management systems, operation management systems, sales 
management systems, human resource systems, accounts receivable systems, accounts 
payable systems, capital asset systems, inventory systems, invoicing systems, payroll 
systems, enterprise resource planning systems (ERP), material requirement planning 
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systems (MRP), scheduling systems, supply chain systems, quality control systems, 
purchasing systems and combinations thereof. 

151 . The system of claim 150, wherein at least some data are pre-specified for integration and 
conversion. 

152. The system of claim 150, wherein a metadata and conversion rules window is used to 
establish a metadata mapping table and a conversion rules table. 

153. The system of claim 150, wherein a common schema identifies data designations 
selected from the group consisting of components of value, sub components of value, known 
value drivers, elements of value, sub elements of value, non-relevant attributes and 
combinations thereof. 

154. The system of claim 150, wherein at least a portion of the data are obtained from an 
Internet or an external database. 

155. A program storage device readable by machine, tangibly embodying a program of 
instructions executable by a machine to perform the method steps in a data processing method, 
comprising: 

use metadata mapping to integrate a plurality of data from a plurality of enterprise related 
systems in accordance xml and a common schema to support organization processing 
where metadata mapping is guided by a metadata mapping table and 
where a metadata and conversion rules window is used to establish a metadata mapping 
table. 

156. The program storage device of claim 155, wherein at least some data are pre-specified 
for integration and conversion 

157. The program storage device of claim 155, wherein a plurality of integrated enterprise data 
are stored in an application database in accordance with a common schema. 

158. The program storage device of claim 155, wherein a plurality of enterprise related 
systems are selected from the group consisting of advanced financial systems, basic financial 
systems, alliance management systems, brand management systems, customer relationship 
management systems, channel management systems, intellectual property management 
systems, process management systems, vendor management systems, operation management 
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systems, sales management systems, human resource systems, accounts receivable systems, 
accounts payable systems, capital asset systems, inventory systems, invoicing systems, payroll 
systems, enterprise resource planning systems (ERP), material requirement planning systems 
(MRP), scheduling systems, supply chain systems, quality control systems, purchasing 
systems, risk management systems, the Internet and combinations thereof. 

159. A data method, comprising using metadata mapping to integrate a plurality of data from a 
plurality of enterprise related systems in accordance with xml and a common schema to support 
organization processing where metadata mapping is guided by a metadata mapping table and 
where a metadata and conversion rules window is used to establish a metadata mapping table. 

160. The method of claim 159, wherein a plurality of enterprise related systems are selected 
from the group consisting of advanced financial systems, basic financial systems, alliance 
management systems, brand management systems, customer relationship management 
systems, channel management systems, intellectual property management systems, process 
management systems, vendor management systems, operation management systems, sales 
management systems, human resource systems, accounts receivable systems, accounts 
payable systems, capital asset systems, inventory systems, invoicing systems, payroll systems, 
enterprise resource planning systems (ERP), material requirement planning systems (MRP), 
scheduling systems, supply chain systems, quality control systems, purchasing systems, risk 
management systems, the Internet and combinations thereof. 

161. The method of claim 159, wherein a metadata and conversion rules window is used to 
establish a metadata mapping table and a conversion rules table. 

162. The method of claim 159, wherein a common schema identifies data designations 
selected from the group consisting of components of value, sub components of value, known 
value drivers, elements of value, sub elements of value, non-relevant attributes and 
combinations thereof. 

163. The method of claim 159, wherein a data method further comprises storing a plurality of 
converted data in one or more tables to support organization processing. 

164. A data preparation system, comprising: 

a computer with a processor having circuitry to execute instructions; a storage device available 
to said processor with sequences of instructions stored therein, which when executed cause 
the processor to: 



Serial No: 09/940,450 



29 



use metadata mapping to integrate and convert a plurality of data from a plurality of 
enterprise related systems in accordance with xml and a common schema to support 
organization processing 

where metadata mapping is guided by a metadata mapping table, 

where a metadata and conversion rules window is used to establish a metadata mapping 
table, and 

where a plurality of enterprise related systems are selected from the group consisting of 
advanced financial systems, basic financial systems, alliance management systems, 
brand management systems, customer relationship management systems, channel 
management systems, intellectual property management systems, process management 
systems, vendor management systems, operation management systems, sales 
management systems, human resource systems, accounts receivable systems, accounts 
payable systems, capital asset systems, inventory systems, invoicing systems, payroll 
systems, enterprise resource planning systems (ERP), material requirement planning 
systems (MRP), scheduling systems, supply chain systems, quality control systems, 
purchasing systems and combinations thereof. 

165. The system of claim 164, wherein at least some data are pre-specified for integration and 
conversion. 

166. The system of claim 164, wherein a common schema identifies data designations 
selected from the group consisting of components of value, sub components of value, known 
value drivers, elements of value, sub elements of value, non-relevant attributes and 
combinations thereof. 

167. The system of claim 164, wherein at least a portion of the data are obtained from an 
Internet or an external database. 
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ABSTRACT 



A data integration system and method gathers information 
dynamically from one or more data sources, which may be 
located at different servers and have incompatible formats, 
structures the information into a configurable, object- 
oriented information model, and outputs the information for 
the user according to an associated, configurable visual 
representation with automatic content classification. 

27 Claims, 12 Drawing Sheets 
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SYSTEM AND METHOD FOR RETRIEVING 
ENTITIES AND INTEGRATING DATA 

RELATED APPLICATIONS 

This application is a continuation-in-part of U.S. patent 5 
application Ser. No. 08/915,662, filed Aug. 21, 1997, now 
U.S. Pat. No. 5,999,940 entitled "Interactive Discovery Tool 
and Methodology," issued on Dec. 7, 1999 by Denis Ranger, 
the contents of which are incorporated by reference herein, lQ 
and claims the benefit of U.S. Provisional Application No. 
60/056,523, entitled "Method of Data Integration," filed on 
Aug. 21, 1997 by Denis Ranger, the contents of which are 
incorporated by reference herein. 

FIELD OF THE INVENTION 15 

The present invention relates to data processing and, more 
particularly, to information discovery and visualization. 

BACKGROUND OF THE INVENTION 20 

There is a vast amount of information in the world today 
that is available by computer. For example, on the World 
Wide Web alone there are millions of web pages. In addition 
to the Internet, companies have set up local "intranets" for 
storing and accessing data for running their organizations. 25 
However, the sheer amount of available information is 
posing increasingly more difficult challenges to conven- 
tional approaches. 

A major difficulty to overcome is that information rel- 3Q 
evant to a purpose of a user is often dispersed across the 
network at many sites. It is often time-consuming for a user 
to visit all these sites. One conventional approach is a search 
engine. A search engine is actually a set of programs 
accessible at a network site within a network, for example a 
local area network (LAN) at a company or the Internet and 
World Wide Web. One program, called a "robot" or "spider," 
pre-traverses a network in search of documents and builds 
large index files of keywords found in the documents. 

Auser of the search engine formulates a query comprising 40 
one or more keywords and submits the query to another 
program of the search engine. In response, the search engine 
inspects its own index files and displays a list of documents 
that match the search query, typically as hyperlinks. When 
a user activates one of the hyperlinks to see the information 45 
contained in the document, the user exits the site of the 
search engine and terminates the search process. 

Search engines, however, have their drawbacks. For 
example, a conventional search engine suffers from obso- 
lescence of data in its search indexes due to pre-traversing 50 
a network to index documents. Documents are constantly 
being updated, but it may take months for the new infor- 
mation to filter down to search engines. Furthermore, a 
search engine is oriented to discovering textual information 
only. In particular, conventional search engines are not 55 
well-suited to indexing information contained in structured 
databases, e.g. relational databases, and mixing data from 
incompatible data sources is difficult in conventional search 
engines. 

Attempts have been made to present search results in an 60 
object-oriented fashion by homogenizing the search results 
into an "entity" that is an instance of a specified class, which 
may be hierarchically dependent upon another "base" class. 
A class specifies the attributes or properties of an entity, and 
a dependent class includes the attributes of the base class and 65 
additional attributes. A problem with such attempts is that 
the particular data returned for a particular entity is restricted 
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to the attributes defined for the specified class of the entity. 
This restriction means that if the entity to be returned 
actually belongs to a dependent class, hierarchically depen- 
dent upon the specified class, the number of attributes 
returned to the user will be limited to the properties for the 
base class, not the dependent class. Consequently, some 
search results will be not be found and presented to the user. 
If, however, the user wants to check if a particular entity 
belongs to a dependent class, another query to the system 
has to be submitted, specifying the particular dependent 
class. This checking operation becomes more time consum- 
ing as more dependent classes are specified and more 

SUMMARY OF THE INVENTION 

There exists a need for a mechanism to collect relevant 
information located at a plurality of sites and stored in 
plurality of incompatible formats according to configurable 
search strategies. 

These and other needs are met by the present invention, 
which dynamically gathers information from a diversity of 
data sources with agents, organizes the information in an 
configurable, information model, and visualizes the infor- 
mation according to a view. 

Accordingly, one aspect of the invention relates to an 
entity retrieving system connectable to at least one data 
source comprising a memory and a processor connected to 
an interface. The memory stores a number of classes, in 
which each class defines the structure of an entity, including 
property definitions that identify property values stored in 
the data sources and to be retrieved dedicated to the property 
definition. The classes include at least one dependent class 
that is hierarchically linked to at least one other class and 
contains additional property definitions specifying addi- 
tional property values, in addition to the property values of 
the class from which it depends. 

The processor, in cooperation with the interface, is con- 
figured for receiving a query, which includes an identifier for 
identifying a particular class and at least one of the property 
values. The processor also selects, among the classes, the 
particular class dedicated to the identifier under control of 
said query, accesses the data sources, retrieves property 
values pertaining to at least one particular entity that com- 
prises that property value, and outputs the retrieve entities. 
Upon establishing that the particular entity pertains to one of 
said dependent classes of the selected particular class, the 
processor is configured to retrieve the additional properties 
of the dependent class. According to another aspect, the 
processor is configured for invoking a plurality of agents 
concurrently to gather the requested information from the 

Additional objects, advantages, and novel features of the 
present invention will be set forth in part in the description 
that follows, and in part, will become apparent upon exami- 
nation or may be learned by practice of the invention. The 
objects and advantages of the invention may be realized and 
obtained by means of the instrumentalities and combinations 
particularly pointed out in the appended claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example, 
and not by way of limitation, in the figures of the accom- 
panying drawings and in which like reference numerals refer 
to similar elements and in which: 

FIG. 1 is a high-level block diagram of a computer system 
with which an embodiment of the present invention can be 
implemented. 
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payroll purposes. When an "employee" instance is resolved, 
the actual class of the instance is one of the two subclass, 
"exempt" or "nonexempt." 

On the other hand, if such an instance is not cached in the 
data layer 210, then the instance is instantiated in step 504 5 
with attributes initialized from the seed parameter and the 
default values in the attribute description, e.g. in the 231-5 
field. Instantiation results in the creation of a new entry in 
the "Instances" table 215 with a unique instance identifier 
being stored in the "Instance" field 215-1. In addition, the :o 
"Agent Seed" field 215-5 is initialized to the seed parameter 
and the "Agent State" field 215-4 is cleared. 

In step 506, a "puzzle" is set up that determines which 
agents are to be invoked for gathering information for the 
new instance. These agents may be agents specified for the 15 
class identified by the class parameter ("class agents") and 
non-local agents of superclasses of the class ("non-local 
superclass agents"). In one embodiment, agents are listed in 
respective entries of the "Agents" table 227. Class agents are 
determined from entries in which the class identifier in the 20 
"Class" field 227-2 matches the class parameter received in 
step 500. Non-local superclass agents are determined from 
entries in which the "Local" field 227-9 is false and the class 
identifier in the "Class" field 227-2 matches the class 
identifier specified in the "Superclass" field 229-1 of the "Is 25 
A" table 229 wherein the corresponding "Subclass" field 
229-2 contains the class identifier matching the input class 
parameter. 

As described in more detail hereinafter, the puzzle is run, 3Q 
invoking agent to gather data and then integrating the data 
into one or more entities (step 508). If successful, the one or 
more entities are cached in the data layer 210 (step 510), 
setting the "Expiration" field 215-3, as appropriate. For 
example, the "Expiration" field 215-3 may contain the 3J 
termination date of a mortal object (cf. the "Life Span" field 
225-4). When a mortal object has expired, it is removed 
from the data layer 210. Finally, the instance identifier and 
the actual class, possibly changed due to a mutation, of the 
instance is returned in step 512. 

Since agents are invoked when an instance is resolved, 
information that is potentially more up-to-date can be 
retrieved than through conventional search engines. Con- 
ventional search engines pre-traverse the web to build their 
index files, which may become out of date for months until 45 
the search index is re-updated. With the present invention, 
however, the "Life Span" attribute controls how long any 
information object is cached, reducing the obsolescence of 
information stored at the server to individually acceptable 
levels, e.g. caching for only a month. 50 

Invoking Agents 
Referring to FIG. 6, running a puzzle results in invoking 
agents to dynamically access, collect, and integrate "pieces" 
of data from data sources. More specifically, the agents 55 
associated with the class (and superclasses) of the entity to 
be retrieved are examined. In step 600, queries are built as 
a combination of an agent and a "pieece" of information as 
an input parameter, typically a previously determined 
attribute for the entity to be retrieved such as a seed value. 60 
For example, an agent may get additional information about 
a person based on a social security number. Given the social 
security number, a query is created in conjunction with the 
agent, using the social security number as an input param- 

On systems that support multi-tasking, all the built que- 
ries are launched concurrently at step 602. Launching a 
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query involves invoking (or executing) an agent with the 
corresponding piece of information as an input value. The 
result of launching a query is a result code and, if 
appropriate, a list of pieces. The result codes are 
REFRESH_AND_CONTINUE, REFRESH_AND_ 
QUIT, FAIL_AND_CONTINUE, and FAIL_AND_ 
QUIT. "REFRESH" means that the query was successful, 
while "FAIL" means that the query was unsuccessful (e.g. 
time out or not found in the data source). "CONTINUE" 
means that the result is incomplete and "QUIT" means that 
the query result is controlling, whether successful or unsuc- 
cessful. A piece is an attribute, value pair, such as "Name= 
'Bob Smith'". 

Generally, agents come in two flavors, attribute agents 
and content agents, specified in the "Type" field 227-5 of the 
"Agents" table 227. An attribute agent is responsible for 
gathering information about an instance itself, for example, 
getting the author of a document, the size of the document, 
and creation date. Attribute agents are normally invoked 
during instance resolution, which takes place the first time 
the value of an attribute is requested. In the example, the 
agent that discovered the length of employment for an 
employee from an authoritative database is an attribute 

Content agents are responsible for gathering the content 
of the object, for example, getting files in a directory, 
graphics from a web page, or names from a telephone book. 
Content agents are invoked whenever content of the object 
is first accessed, usually when producing a visualization for 
the object's space. In the example, the agent that discovered 
files in a directory is a content agent. 

To support concurrent query execution, queries use a 
common "blackboard" to post their results. When a query is 
launched, the blackboard is first checked for an entry listing 
the agent and piece. If the entity is incomplete, because 
another query is currently running, then the query waits until 
the result from the running query is available and returns the 
result posted on the blackboard. On the other hand, if there 
is not entry for the agent and piece, then such an entry in the 
blackboard is created, the agent is invoked, and the results 
are posted on to the blackboard and returned. 

When an agent is invoked, it is passed an instance 
identifier for accessing and modifying attributes of the 
instance being resolved and the input seed value. For 
example, if the instance is a member of a "employee" class 
and the seed value is an employee number, the agent is 
passed an identifier of the instance and the employee num- 
ber. The agent may use the employee number to query an 
authoritative database (cf. the "Authoritative" field 227-11), 
parse the result to determine some values of attributes (such 
as length of employment), and initialize the attributes with 
the parsed values. As another example, a "directory" object 
may use a pathname as a seed value. The contents, e.g. files 
and other directories, of a directory having that pathname 
may be inspected by the agent for creating file objects as 
contents of the directory object. 

At step 604, the results of launching the queries are 
processed as they come in. If the query failed to run due to 
a timeout condition (e.g. with a result code of FAIL_AND_ 
CONTINUE), then the query is placed on a failed queries 
list. If the query has failed and the agent is considered to be 
authoritative (result code of FAIL_AND_QUIT), then all 
remaining agents are marked as done and the search for this 
puzzle is terminated. If the query has failed, but not due to 
a time-out (also FAIL_AND_CONTINUE), then the agent 
is simply marked as done, but the other, concurrently 
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invoked agents are allowed to continue. Results of a content 
query are added to the content of the current result. Attribute 
queries, on the other hand, add their results to the attributes 
of the current result. Failed queries are retried in step 606. 

In the example illustrated in FIG. 9, an agent dedicated to 5 
the Product class, is provided for retrieving the Supplier and 
Type property values based on the ID number. These prop- 
erty values are for example stored in an internal data source, 
for example a relational database 246. The agent comprises 
an address in field Origin 227-13 indicating the path name 10 
of the database 246 data source. In order to enable to retrieve 
data from different types of data sources, there are provided 
different types of agents. For a relational database such as 
Oracle ®, the agent is an ODBC agent type. The agent 
further comprises a series of instructions indicating which 15 
data from the addressed data source are to be retrieved by the 
agent, for example: 

"SELECT Key, Type, Supplier FROM Products" 

The agent further comprises in its agent parameters 228 
for assigning, for each property value to be retrieved, a 20 
portion of the data to one of the property definitions. In this 
case, "Key" is assigned to "ID" property definition, "Type" 
to "Type" property definition and "Supplier" to "Supplier" 
property definition. 

This agent co-operates with interface 111 for accessing 25 
the data source, under control of processor 104 and for 
retrieving the requested data. In the example mentioned 
hereinabove, the following data will be returned: "93- 
21123" forming the ID, "Doubleday" forming the Supplier 
and "Book" forming the type. 30 

Data Integration 

When several agents retrieve, from different data sources, 
property values that should correspond, some property val- 
ues retrieve might not be equal to each other. For example, 35 
a customer's telephone number may be recorded differently 
in two data sources, or there might be three different authors 
for the same book title. In the first case, it is probable that 
the same customer has two phone numbers (an 
inconsistency), in the second case, we may be dealing with 40 
three altogether different books (an ambiguity). 

Inconsistencies and ambiguities are virtually unavoidable 
when integrating multiple data sources that were not con- 
ceived together and that may not even be managed by the 
same organization. There is therefore a need for appropri- 45 
ately handling ambiguities and inconsistencies within data. 
The manner in which an embodiment handles these prob- 
lems is explained by means of an example. 

Assume that agents are looking for a Person named Bob 
Smith. Agent A is configured to look for a person's address 50 
given the person's name. Agents B and C are configured to 
look for a person' age given the person's name, each agent 
targeting a separate data source. This example is illustrated 
in FIG. 10. 

Agent A returns with not one but two "Bob Smith", one 55 
living in New York and the other in Newark. Determining 
whether there are two persons named Bob Smith or only one 
with a conflicting address depends on how much to trust 
Agent A to be accurate or, in other words, whether its data 
source contains the correct addresses. For this purpose, a 60 
reliability or confidence parameter 227-8 is assigned to the 
agent. If the confidence parameter for agent A is 100%, then 
there are two persons named Bob Smith and two entities are 
thus shown to the user. On the other hand, if Agent A has a 
confidence parameter of only 10%, then the one entity is 65 
produced, showing two possibilities for a property value, 
e.g. "New York OR Newark". 
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Assume now agent A has a 100% reliability parameter. 
Agent B and C for the Bob Smith in New York obtain his 
age. Both agree that it is 35. However agents B and C for the 
Bob Smith in Newark disagree about his age. Agent B 
indicates 24 and Agent C 27. In this case, Agents B and C 
are fallible, but their disagreement is not sufficient grounds 
to see two separate persons named Bob Smith living in 
Newark. If Agents B and C have substantially the same 
reliability parameter that is relatively low, for example 10%, 
then one entity will be presented to the user with an 
indication of two property values for the age: "24 OR 27", 
such as illustrated in FIG. 10. In this situation, there is a 
"conflict of opinion" between data sources about the age the 
Bob Smith living in Newark. Because of ambiguities and 
inconsistencies, a request to an embodiment to find an entity 
may end up returning more than one entity, with some 
"conflicts of opinion" about some of them. When this 
occurs, the user is presented with a display using the generic 
template 239-5 for the requested view, e.g. a Web page, that 
gives a choice between these entities and highlights con- 
flicts. 

If Agents B and C have substantially the same reliability 
parameter, which is relatively high, for example 90%, then 
on embodiment interprets that there are two distinct entities 
as being two separate entities which will be presented to the 
user, each with its own age. If agent B is substantially more 
reliable than agent C, for example agent B is at least 25% 
more reliable than agent C, then an embodiment will prefer 
the property value retrieved by agent B, i.e. 24, and only the 
entity retrieved having this value will be presented to the 

Consequently, providing a reliability parameter for 
agents, inconsistencies and ambiguities in property values 
can be interpreted, filtering out unreliable property values or 
presenting them in an appropriate fashion to the user. 

When it is determined that two or more entities are to be 
created, for example two persons named Bob Smith, 
instances are created for each new entity. For each new 
entity, a new corresponding sub-puzzle is set up and then 
run. At this point, the top-level puzzle switches to a passive 
mode in which the top-level puzzle waits for all the sub- 
puzzles to finish and return their results recursively. 

Mutations 

Sometimes, information discovered for an entity, typi- 
cally by an attribute agent, causes the entity to change its 
class. Accordingly, the entity is checked if a mutation should 
be performed to change the class of the entity (step 608). In 
a particular check, mutation patterns or mutation agents 
dedicated to one of the dependent classes of the current 
entity are checked. This checking can be performed by 
verifying, for each dependent class, if the mutative field 
229-4 is true. If true, then mutation patterns or mutation 
agents dedicated to the classes "Book" and "Audio Tape" are 
examined. A mutation pattern dedicated to the classes book 
comprises a condition, for example: "If the Product Type 
="book" then mutate the Product into a Book", which is 
evaluated to determine if the found property value for the 
product type falls within the condition. For this purpose, the 
processor 102 compares the property values stored in the 
memory 104 with the condition of the mutation pattern. In 
the example, the retrieved property for the product type is a 
"Book". Thus, a mutation occurs and the class of the entity 
becomes "Book" causing additional property values pertain- 
ing to the class "Book" to be retrieved. A mutation agent is 
a stored procedure or other piece of procedural logic that can 
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ABSTRACT 



A system, method and article of manufacture are provided 
for implementing communication services patterns. A fixed 
format stream-based communication system is provided and 
service is delivered via a globally addressable interface. 
Access is afforded to a legacy system. Service is delivered 
via a locally addressable interface. A null value is commu- 
nicated and data is transmitted from a server to a client via 
pages. A naming service and a client are interfaced with the 
naming service allowing access to a plurality of different sets 
of services from a plurality of globally addressable inter- 
faces. A stream-based communication system is provided 
and data is efficiently retrieved. 

15 Claims, 123 Drawing Sheets 
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FIG. 16 illustrates File Sharing : 

FIG. 17 depicts Message Passing : 

FIG. 18 depicts Message Queuing s 

FIG. 19 illustrates Publish and Subscribe services; 

FIG. 20 depicts Streaming, in which a real-time data 
stream is transferred; 

FIG. 21 illustrates CORBA-based Object Messaging; 

FIG. 22 illustrates COM Messaging; 

FIG. 23 represents CTI Messaging; 

FIG. 24 illustrates various components of the Communi- 
cation Fabric of the present invention; 

FIG. 25 illustrates the two categories of the Physical 
Media; 

FIG. 26 illustrates several of the components of the 
Transaction areas of the Netcentric Architecture Framework; 

FIG. 27 illustrates various components of the Environ- 
mental Services of the Netcentric Architecture Framework; 

FIG. 28 illustrates the Base Services of the Netcentric 
Architecture Framework; 

FIG. 29 shows the major components of the reporting 
application framework; 

FIG. 30 illustrates an example of how a custom report 2 s 
architecture relates to a workstation platform technology 
architecture; 

FIG. 31 describes the relationships between the major 
components of the report process and the report writer 
process; 30 

FIG. 32 shows the module hierarchy for the custom report 
process; 

FIG. 33 depicts the various components of the Business 
Logic portion of the Netcentric Architecture Framework; 

FIG. 34 illustrates a relationship between major themes 
that impact aspects of software development and manage- 

FIG. 35 illustrates how components are viewed from 
different perspectives; 40 

FIG. 36 shows a relationship between business compo- 
nents and partitioned business components; 

FIG. 37 shows how a Billing Business Component may 

FIG. 38 illustrates the relationship between the spectrum 45 
of Business Components and the types of Partitioned Busi- 
ness Components; 

FIG. 39 illustrates the flow of workflow, dialog flow, 
and/or user interface designs to a User Interface Component; 5Q 

FIG. 40 is a diagram of an Application Model which 
illustrates how the different types of Partitioned Business 
Components might interact with each other; 

FIG. 41 illustrates what makes up a Partitioned Business 
Component; 55 

FIG. 42 illustrates the role of patterns and frameworks; 

FIG. 43 illustrates this Business Component Identifying 
Methodology including both Planning and Delivering 
stages; 

FIG. 44 shows a high level picture of application com- 
ponent interaction for an Order Entry system; 

FIG. 45 illustrates a traditional organization structure 
including an activities component, a credit/collections 
component, a billing component, and a finance component; ( 

FIG. 46 provides an illustration of a horizontal organiza- 
tion model; 



FIG. 47 illustrates a workcell organization approach 
including an activities component, a credit/collections 
component, a billing component, and a finance component; 

FIG. 48 illustrates the Enterprise Information Architecture 
(EIA) model; 

FIG. 49 illustrates a V-model of Verification, Validation, 
and Testing; 

FIG. 50 portrays of a development architecture with a 
D seamless integration of tools which can be plugged in for the 
capture and communication of particular deliverables; 

FIG. 51 shows a design architecture with the compro- 
mises made for today's component construction environ- 

5 FIG. 52 illustrates a business process to object mapping; 
FIG. 53 is a diagram which illustrates a graph of resilience 
to change; 

FIG. 54 illustrates a flowchart for a method for providing 
an abstraction factory pattern in accordance with an embodi- 

FIG. 55 illustrates a flowchart for a method for represent- 
ing a plurality of batch jobs of a system each with a unique 
class in accordance with an embodiment of the present 



FIG. 56 illustrates a class diagram of the batch job 
hierarchy; 

FIG. 57 illustrates an object interaction graph of a pos- 
sible implementation of the class diagram of FIG. 56; 

FIG. 58 illustrates a flowchart for a method for controlling 
access to data of a business object via an attribute dictionary 
in accordance with an embodiment of the present invention; 

FIG. 59 illustrates a flowchart for a method for structuring 
batch activities for simplified reconfiguration in accordance 
with an embodiment of the present invention; 

FIG. 60 illustrates the manner in which the AttributeDic- 
tionaryClient is the facade which delegates to the Attribute- 
Dictionary; 

FIG. 61 depicts the use of the containsKey() method on 
the HashMap to ensure that the value will exist before the 
get() method is used; 

FIG. 62 illustrates a method that dictates that any 
nullPointerException that is thrown would be caught and 
rethrown as the more user-friendly exception in the attribute 
dictionary pattern environment; 

FIG. 63 illustrates the Get the Attribute Names method in 
the attribute dictionary pattern environment; 

FIG. 64 illustrates a flowchart for a method for managing 
constants in a computer program in accordance with an 
embodiment of the present invention; 

FIG. 65 illustrates a flowchart for a method for providing 
a fixed format stream-based communication system in 
accordance with an embodiment of the present invention; 

FIG. 66 illustrates two systems communicating via a 
stream-based communication and using a common generic 
format to relay the meta-data information; 

FIG. 67 illustrates an example of a Fixed Format message 
associated with the fixed format stream patterns; 

FIG. 68 depicts the complete Fixed Format Stream pattern 
associated with the fixed format stream patterns; 

FIG. 69 illustrates fixed format contracts containing meta- 
data information for translating structured data onto and off 
of a stream; 

FIG. 70 illustrates a Customer object in an object-based 
system streaming itself into a stream, the stream being sent 
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ing key data-window relationship. This allows the user to 
work in a controlled and, well managed, environment. 

Web Browser 1308 

Web Browser Services allow users to view and interact 5 
with applications and documents made up of varying data 
types, such as text, graphics, and audio. These services also 
provide support for navigation within and across documents 
no matter where they are located, through the use of links 
embedded into the document content. Web Browser Services 10 
retain the link connection, i.e., document physical location, 
and mask the complexities of that connection from the user. 
Web Browser services can be further subdivided into: 
Browser Extension, Form, and User Navigation. 

Parlez-vous Internet? 15 
The Elements of Web Style 

Language philosopher Benjamin Whorf once said, "We 
dissect nature along lines laid down by our native language. 
Language is not simply a reporting device for experience, 
but a defining framework for it." This notion is especially 20 
true when applied to the World Wide Web. The evolution of 
the Web from a rigid, text-centric village to an elastic, 
multimedia-rich universe has been driven by modifications 
to the languages behind it. The Internet is at a crucial point 
in its development as a number of enhancements for extend- 25 
ing Web technology come under scrutiny by Internet stan- 
dards groups. These enhancements will ultimately push the 
Web into the realms of distributed document processing and 
interactive multimedia. 

SGML: in the beginning ... 30 

Although the World Wide Web was not created until the 
early 1990s, the language behind it dates back to the genesis 
of the Internet in the 1960s. Scientists at IBM were working 
on a Generalized Markup Language (GML) for describing, 
formatting, and sharing electronic documents. Markup 35 
refers to the practice in traditional publishing of annotating 
manuscripts with layout instructions for the typesetters. 

In 1986, the International Standards Organization (ISO) 
adopted a version of that early GML called Standard Gen- 
eralized Markup Language (SGML). SGML is a large and 40 
highly-sophisticated system for tagging documents to ensure 
that their appearance will remain the same regardless of the 
type of platform used to view them. Designers use SGML to 
create Document Type Definitions (DTDs), which detail 
how tags (also known as format codes) are defined and 45 
interpreted within specified documents. These tags can be 
used to control the positioning and formatting of a docu- 
ment's text and images. SGML is used for large, complex, 
and highly-structured documents that are subject to frequent 
revisions, such as dictionaries, indexes, computer manuals, 50 
and corporate telephone directories. 

HTML: SGML for dummies? 

While creating the World Wide Web in the early 1990s, 
scientists at CERN discovered that in spite of its power and 
versatility, SGML's sophistication did not allow for quick 55 
and easy Web publishing. As a result, they developed 
HyperText Markup Language (HTML), a relatively simple 
application of SGML. This simplicity has contributed to the 
exponential growth of the Web over the last few years. 
HTML files are written in plain text and can be created using 60 
any text editor from the most robust Web page authoring 
software (such as Microsoft's FrontPage or Sausage Soft- 
ware's HotDog) to the anemic Notepad utility included with 
Microsoft's Windows operating system. 

As with many languages, HTML is in a state of constant 65 
evolution. The World Wide Web Consortium W3C oversees 
new extensions of HTML developed by both software 
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companies (such as Microsoft and Netscape 
Communications) and individual Web page authors and 
ensures that each new specification is fully-compatible with 
previous ones. Basic features supported by HTML include 
headings, lists, paragraphs, tables, electronic forms, in-line 
images (images next to text), and hypertext links. Enhance- 
ments to the original HTML 1.0 specification include 
banners, the applet tag to support Java, image maps, and text 
flow around images. 

The W3C also approved the specification for version 4.0 
of HTML (http://www.w3.org/TR/REC-html40). This speci- 
fication builds upon earlier iterations of HTML by enabling 
Web authors to include advanced forms, in-line frames, and 
enhanced tables in Web pages. HTML 4.0 also allows 
authors to publish pages in any language, and to better 
manage differences in language, text direction, and character 
encoding. 

Perhaps most significantly, HTML 4.0 increases authors' 
control over how pages are organized by adding support for 
Cascading Style Sheets CSS Style sheets contain directions 
for how and where layout elements such as margins, fonts, 
headers, and links are displayed in Web pages. With CSS, 
authors can use programming scripts and objects to apply 
multiple style sheets to Web pages to create dynamic con- 
tent. CSS can also be used to centralize control of layout 
attributes for multiple pages within a Web site, thus avoiding 
the tedious process of changing each page individually. 

Dynamic HTML: Dyn-o-mite! 

HTML's simplicity soon began to limit authors who 
demanded more advanced multimedia and page design 
capabilities. Enter Dynamic HTML DHTML As an exten- 
sion of HTML, DHTML allows Web pages to function more 
like interactive CD-ROMs by responding to user-generated 
events. DHTML allows Web page objects to be manipulated 
after they have been loaded into a browser. This enables 
users to shun plug-ins and Java applets and avoid 
bandwidth-consuming return trips to the server. For 
example, tables can expand or headers can scurry across the 
page based on a user's mouse movements. 

Unfortunately, the tremendous potential offered by 
DHTML is marred by incompatible standards. At the heart 
of the DHTML debate is a specification called the Document 
Object Model DOM The DOM categorizes Web page 
elements — including text, images, and links — as objects and 
specifies the attributes that are associated with each object. 
The DOM makes Web document objects accessible to 
scripting languages such as JavaScript and VisualBasic 
Script (VBScript), which can be used to change the 
appearance, location, and even the content of those objects 

Microsoft's Internet Explorer 4.0 supports a W3C "Work- 
ing Draft" DOM specification that uses the CSS standard for 
layout control and Web document object manipulation. In 
contrast, Netscape's implementation of DHTML in Com- 
municator 4.0 uses a proprietary "Dynamic Layers" tag, 
which assigns multiple layers to a page within which objects 
are manipulated. As a result, Web pages authored using 
either version of DHTML may not be viewed properly using 
the other's browser. XML: X marks the spot 

HTML 4.0 and Dynamic HTML have given Web authors 
more control over the ways in which a Web page is dis- 
played. But they have done little to address a growing 
problem in the developer community: how to access and 
manage data in Web documents so as to gain more control 
over document structure. To this end, leading Internet devel- 
opers devised Extensible Markup Language (XML), a 
watered-down version of SGML that reduces its complexity 
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while maintaining its flexibility. Like SGML, XML is a 
meta-language that allows authors to create their own cus- 
tomized tags to identify different types of data on their Web 
pages. In addition to improving document structure, these 
tags will make it possible to more effectively index and 5 
search for information in databases and on the Web. 

XML documents consist of two parts. The first is the 
document itself, which contains XML tags for identifying 
data elements and resembles an HTML document. The 
second part is a DTD that defines the document structure by to 
explaining what the tags mean and how they should be 
interpreted. In order to view XML documents, Web brows- 
ers and search engines will need special XML processors 
called "parsers." Currently, Microsoft's Internet Explorer 
4.0 contains two XML parsers: a high-performance parser is 
written in C++ and another one written in Java. 

A number of vendors plan to use XML as the underlying 
language for new Web standards and applications. Microsoft 
uses XML for its Channel Definition Format, a Web-based 
"push" content delivery system included in Internet Explorer 20 
4.0. Netscape will use XML in its Meta Content Framework 
to describe and store metadata, or collections of information, 
in forthcoming versions of Communicator. XML is currently 
playing an important role the realm of electronic commerce 
via the Open Financial Exchange, an application developed 25 
by Microsoft, Intuit, and CheckFree for conducting elec- 
tronic financial transactions. Similarly, HL7, a healthcare 
information systems standards organization, is using XML 
to support electronic data interchange EDI of clinical, 
financial, and administrative information (http:// 30 
www.mcis.duke.edu/standar ds/HL7/sigs/sgml/index.html). 

Meet cousin VRML 

In 1994, a number of Internet thought leaders, including 
Tim Berners-Lee — the "father" of the Web — met to deter- 
mine how they could bring the hot, new technology known 35 
as virtual reality VR to the Web. VR refers to the use of 
computers to create artificial and navigable 3-D worlds 
where users can create and manipulate virtual objects in real 
time. This led to the creation of Virtual Reality Modeling 
Language (VRML — pronounced "ver-mul"). VRML is tech- 40 
nically not a markup language because it uses graphical 
rather than text-based file formats. 

In order to create 3-D worlds and objects with VRML, 
users need a VRML editor such as Silicon Graphics' Cosmo 
Worlds (http://cosmo.sgi.com/products/studio/worlds). To 45 
view VRML content, users need either a VRML browser or 
a VRML plug-in for standard HTML browsers. Leading 
VRML plug-ins include Cosmo Player from Silicon Graph- 
ics (http://vrml.sgi.com/cosmoplayer), Liquid Reality from 
Microsoft's DimensionX subsidiary (http:// 50 
www.microsoft.com/dimensionx), OZ Virtual from OZ 
Interactive (http://www.oz.com/ov/main_bot.html), and 
World View from Intervista (http://www.intervista.com/ 
products/worldview/index.html), These plug-ins can typi- 
cally be downloaded for free from the Web. 55 

VRML is capable of displaying static and animated 
objects and supports hyperlinks to multimedia formats such 
as audio clips, video files, and graphical images. As users 
maneuver through VRML worlds, the landscape shifts to 
match their movements and give the impression that they are 60 
moving through real space. The new VRML 2.0 specifica- 
tion finalized in August 1996 intensifies the immersive 
experience of VR worlds on the Web by enabling users to 
interact both with each other and with their surroundings. 
Other new features supported by VRML 2.0 include richer 65 
geometry description, background textures, sound and 
video, multilingual text, Java applets, and scripting using 



VBScript and JavaScript. VRML will become a significant 
technology in creating next-generation Internet application 
as the language continues to mature and its availability 



The future: give us a big SMIL 

The Web has come a long way since the codification of 
HTML 1.0. It has moved from simple text-based documents 
that included headings, bulleted lists, and hyperlinks to 
dynamic pages that support rich graphic images and virtual 
reality. So what next for the Web? The answer resides in a 
Synchronized Multimedia Integration Language (SMIL), a 
new markup language being developed by the W3C. SMIL 
will allow Web authors to deliver television-like content 
over the Web using less bandwidth and a simple text editor, 
rather than intricate scripting. 

SMIL is based on XML and does not represent a specific 
media format. Instead, SMIL defines the tags that link 
different media types together. The language enables Web 
authors to sort multimedia content into separate audio, 
video, text, and image files and streams which are sent to a 
user's browser. The SMIL tags then specify the "schedule" 
for displaying those components by determining whether 
they should be played together or sequentially. This enables 
elaborate multimedia presentations to be created out of 
smaller, less bandwidth-consuming components. 
Implementation Considerations 

Many features such as graphics, frames, etc. supported by 
Web Browsers today were not available in initial releases. 
Furthermore, with every new release the functionality sup- 
ported by Web Browsers keeps growing at a remarkable 

Much of the appeal of Web Browsers is the ability to 
provide a universal client that will oiler users a consistent 
and familiar user interface from which many types of 
applications can be executed and many types of documents 
can be viewed, on many types of operating systems and 
machines, as well as independent of where these applica- 
tions and documents reside. 

Web Browsers employ standard protocols such as Hyper- 
text Transfer Protocol (HTTP) and File Transfer Protocol 
(FTP) to provide seamless access to documents across 
machine and network boundaries. 

The distinction between the desktop and the Web Browser 
narrowed with the release of Microsoft IE 4.0, which 
integrated Web browsing into the desktop, and gave a user 
the ability to view directories as though they were Web 
pages. Web Browser, as a distinct entity, may even fade 
away with time. 

Exemplary products that may be used to implement this 
component includes Netscape Navigator; Netscape Commu- 
nicator; Microsoft Internet Explorer; Netscape LiveWire; 
Netscape LiveWire Pro; Symantec Visual Cafe; Microsoft 
Front Page; Microsoft Visual J++; IBM VisualAge. 
Execution Products: 

Netscape Navigator or Communicator — one of the origi- 
nal Web Browsers, Navigator currently has the largest 
market share of the installed browser market and strong 
developer support. Communicator is the newest version 
with add-on collaborative functionality 
Microsoft Internet Explorer (IE) — a Web Browser that is 
tightly integrated with Windows and supports the major 
features of the Netscape Navigator as well as 
Microsoft's own ActiveX technologies. 
Development Products: 

Web Browsers require new or at least revised develop- 
ment tools for working with new languages and standards 
such as HTML, ActiveX and Java. Many browser content 
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call-level SQL variants and supersets. Depending upon the 
underlying storage model, non-SQL access methods may be 
used instead. 

Many of the Netcentric applications are broadcast-type 
applications, designed to market products and/or publish 5 
policies and procedures. Furthermore, there is now a growth 
of Netcentric applications that are transaction-type applica- 
tions used to process a customers sales order, maintenance 
request, etc. Typically these type of applications require 
integration with a database manager. Database Services 10 
include: Storage Services, Indexing Services, Security 
Services, Access Services, and Replication/Synchronization 
Services 

Implementation Considerations 

The core database services such as Security, Storage and 15 
Access are provided by all major RDBMS products, 
whereas the additional services of Synchronization and 
Replication are available only in specific products. 
Product Considerations 

Oracle 7.3; Sybase SQL Server; Informix; IBM DB/2; 20 
Microsoft SQL Server 

Oracle 7.3 — market leader in the Unix client/server 
RDBMS market, Oracle is available for a wide variety 
of hardware platforms including MPP machines. 
Oracles market position and breadth of platform sup- 25 
port has made it the RDBMS of choice for variety of 
financial, accounting, human resources, and manufac- 
turing application software packages. Informix — 
second in RDBMS market share after Oracle, Informix 
is often selected for its ability to support both large 30 
centralized databases and distributed environments 
with a single RDBMS product. Sybase SQL Server- 
third in RDBMS market share, Sybase traditionally 
focused upon medium-sized databases and distributed 
environments; it has strong architecture support for 35 
database replication and distributed transaction pro- 
cessing across remote sites. 
IBM DB2 — the leader in MVS mainframe database 
management, IBM DB2 family of relational database 
products are designed to offer open, industrial strength 40 
database management for decision support, transaction 
processing and line of business applications. The DB2 
family now spans not only IBM platforms like personal 
computers, AS/400 systems, RISC System/6000 hard- 
ware and IBM mainframe computers, but also non- 45 
IBM machines such as Hewlett-Packard and Sun 
Microsystems. Microsoft SQL Server — the latest ver- 
sion of a high-performance client/server relational 
database management system. Building on version 6.0, 
SQL Server 6.5 introduces key new features such as 50 
transparent distributed transactions, simplified 
administration, OLE-based programming interfaces, 
improved support for industry standards and Internet 



Replication/Synchronization 1404 55 

Replication Services support an environment in which 
multiple copies of databases must be maintained. For 
example, if ad hoc reporting queries or data warehousing 
applications can work with a replica of the transaction 
database, these resource intensive applications will not inter- 60 
fere with mission critical transaction processing. Replication 
can be either complete or partial. During complete replica- 
tion all records are copied from one destination to another, 
while during partial replication, only a subset of data is 
copied, as specified by the user or the program. Replication 65 
can also be done either real-time or on-demand (i.e., initiated 
by a user, program or a scheduler). The following might be 



50 

possible if databases are replicated on alternate server(s): 
better availability or recoverability of distributed applica- 
better performance and reduced network cost, particu- 
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Services perform the 
make one or more information sources that are 
mirror each other consistent. This function may 
especially valuable when implementing applications for 
users of mobile devices because it allows a working copy of 
data or documents to be available locally without a constant 
network attachment. The emergence of applications that 
allow teams to collaborate and share knowledge has height- 
ened the need for Synchronization Services in the execution 
architecture. 

The terms Replication and Synchronization are used 
interchangeably, depending on the vendor, article, book, etc. 
For example, when Lotus Notes refers to Replication, it 
means both a combination of Replication and Synchroniza- 
tion Services described above. When Sybase refers tc 
lication it only means copying data from 0 
another. 

Implementation Consideration 

Replication/Synchronization Services ai 
plied as part of commercial databases, document manage- 
ment systems or groupware products such as Lotus Notes, 
Microsoft Exchange, Oracle, etc. 

With Windows 95 and Windows NT 4.0, Microsoft has 
also introduced the concept of Replication/Synchronization 
Services into the operating system. Through the briefcase 
application users can automatically synchronize files and 
SQL data between their Windows PC and a Windows NT 
server. Underlying this application is the user-extensible 
Win32 synchronization services API which can be used to 
build custom synchronization tools. 

Are changes in data usage anticipated? 

Data can be dynamically changed to accommodate 
changes in how the data is used. 

Is it desirable to shield the user from the data access 
process? 

A replicated database often consolidates data from het- 
erogeneous data sources, thus shielding the user from the 
processes required to locate, access and query the data. 

What are the availability requirements of the system? 

Replication provides high availability. If the master data- 
base is down, users can still access the local copy of the 
database. 

Is there a business need to reduce c 

Depending on the configuration (real t: 
replication, etc.), there is a potential to reduce 0 
tions costs since the data access is local. 

Is scalability an issue? 

With users, data, and queries spread across multiple 
computers, scalability is less of a problem. 

Can users benefit from the increased performance of local 
data access? 

Access to replicated data is fast since data is stored locally 
and users do not have to remotely access the master data- 
base. This is especially true for image and document data 
which cannot be quickly accessed from a central site. 
Making automatic copies of a database reduces locking 
conflicts and gives multiple sets of users better performance 
than if they shared the same database. 
Product Considerations 

What is the current or proposed environment? 

Platforms supported as well as source and target DBMS 
should be considered. 
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enables the data access method to be changed at runtime 
(e.g. batch mode, online mode or Request Batcher). 

The Stream-Based Communication pattern can be used to 
stream the business object's data to the handler. The stream 
can then be either forwarded to a Request Batcher or can 
parsed and sent to database. 

Individual Persistence 

FIG. 163 illustrates a flowchart for a method 16300 for 
organizing data access among a plurality of business entities. 
Data about a user is retrieved and packaged into a cross- 
functional data object in operation 16302 and 16304. A 
request for data is retrieved from one of a plurality of 
business objects in operation 16306. In operation 16308, the 
business object are directed to the data object such that the 
business object retrieves the entire data object. The business 
object also selects the data from the data object. 

Both locking and integrity may use a uniform mechanism. 
The business object may retrieve account, customer, and 
bill-related data from the data object. Also, the business 
objects may be able to update themselves independently of 
each other. 

Optionally, new business objects may take advantage of 
existing data access routines. Also, each business object may 
use a uniform access architecture. 

Create a data access architecture that supports reusable, 
independent business objects in the context of atomic, 
functionally-specific transactions. 

A business unit of work, or business transaction, typically 
acts on multiple business entities. But tor each individual 
entity, the transaction might only display and update a few 
data attributes. 

For example, accepting bill payment over the phone 
might use the account number, customer name, amount due, 
date due, and credit card number. The transaction could 
therefore avoid accessing many attributes of the account, 
customer, or monthly bill entities. This might naturally lead 
to a data architecture which only fetches required attributes, 
based on the transaction's needs. 

Indeed, a traditional client/server program retrieves data 
in a piecemeal fashion. In this case, the example program 
would typically allocate a single record to fetch and store the 
required data items. Then, an "accept bill payment" data 
access module would fill this structure. This couples data 
access to processing function. 

FIG. 164 illustrates retrieving data piecemeal. 

This traditional style of data access may seem flexible. 
After all, developers can grab whatever data they need for a 
particular business transaction. 

But such access is very unstructured. Different pieces of 
a cohesive account entity, for example, scatter across mul- 
tiple windows. Some windows will use the account's effec- 
tive date; others will not. 

This also introduces redundancy. Retrieving the date 
requires determining the correct database, table, column, 
and type declaration. Yet another developer who needs this 
date, for a different data set, duplicates the effort. This does 
not encapsulate changes, thereby raising costs for testing, 

Moreover, each transaction must hand-craft its own 
retrieval procedure. Creating the thousandth new business 
transaction would require creating a thousandth new access 
module. Yet all data items would already have been retrieved 
by other modules. This style of data access is not reusable. 

Finally, business entities are typically less likely to change 
than the transactions, or processes, which act on those 
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entities. For example, an enterprise might re-engineer its 
billing function. Regardless of the resulting process, the 
account, customer, and monthly bill objects would likely 
remain. This suggests that transaction-based data access is 
5 brittle. 

Therefore, data access should be organized around busi- 
ness entities, rather than transactions. Individual Persistence 
packages data into cross-functional objects, rather than 
transaction-specific data structures. Each individual busi- 
:o ness object, instead of the window or application, manages 
the retrieval of its data items. 

A business object provides public methods for accessing, 
comparing, displaying, and setting that data. Developers can 
therefore no longer plunder the persistent store, selecting 
15 data items at will. Instead, they must access their data 
through encapsulated, self-requesting business objects. 

With this architecture, the example billing function 
retrieves account, customer, monthly bill, and bill payment 
^ Q objects. 

FIG. 165 illustrates the manner in which the present 
invention retrieves whole objects 16500. 

For reuse, business objects should be able to request and 
update themselves independently of each other. Separating 
25 the data access for customer and account objects supports 
reusing them in isolation. Objects should therefore avoid 
explicitly requesting other linked objects, unless a formal 
containment relationship exists. 

Finally, separation of concern allows business objects to 
30 remain blissfully unaware of the transactions which use 
them. A business object will not know which data items or 
services it may need to provide to its clients. Thus, the object 
must bring back all its data. 
Benefits 

^ Reuse. New transactions can take advantage of existing 
data access routines. For example, introducing a new 
business transaction, like perform credit check, would 
use existing customer and account objects. Yet, these 
domain model objects would already know how to 
update themselves. Therefore, the new application 
would build no new data access code. 
Maintainability and extensibility. This approach supports 
"fix in one place." Any changes to particular data 
elements only need to be changed, tested, and recom- 
piled in one access module, that of the owning business 

Uniformity. Both optimistic locking and referential integ- 
rity (RI) are typically defined at the business object 

50 level. For example, separate account and customer 
objects typically have their own locking attributes. In 
addition, an RI rule usually relates one entity to 
another, such as "all accounts must have a customer." 
Organizing data access around business entities sim- 

55 plifies locking and integrity. Both can use a uniform 
mechanism, implying that the architecture can hide 
technical details. This avoids the hard-coding typical of 
the transaction-based approach. 
Flexibility. Whole object retrieval is extensible. It allows 

60 a transaction to ask an object for any data. This supports 
maintenance and extension. A developer can easily 
change the particular data items a transaction uses. But 
whole retrieval still guarantees that those items will 
already have been retrieved. For example, a future 

65 release of the accept bill payment window could also 
display the social security number. Yet the data access 
routines would need no modification. 
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